home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16402 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.0 KB  |  93 lines
  1. Path: news.wwa.com!rmartin
  2. From: rmartin@oma.com (Robert C. Martin)
  3. Newsgroups: comp.lang.smalltalk,comp.object,comp.lang.c++,comp.lang.java
  4. Subject: Re: The Good, the Bad, the Ugly, and the Wicked ...
  5. Followup-To: comp.lang.smalltalk,comp.object,comp.lang.c++,comp.lang.java
  6. Date: 10 Apr 1996 18:33:35 GMT
  7. Organization: Object Mentor
  8. Message-ID: <RMARTIN.96Apr10133335@rcm.oma.com>
  9. References: <31570B8E.5A12@vmark.com> <4je5rq$7qg@mimas.brunel.ac.uk>
  10.     <4jes0t$gth@decaxp.HARVARD.EDU> <31630E30.5A02@oma.com>
  11.     <4kbq3q$1i8@gaia.ns.utk.edu> <JSA.96Apr9131057@organon.com>
  12. NNTP-Posting-Host: rcm.oma.com
  13. In-reply-to: jsa@organon.com's message of Tue, 9 Apr 1996 17:10:57 GMT
  14.  
  15.  
  16. Robert C. Martin (rmartin@oma.com) wrote:
  17.  
  18.    > : Malloc and new can *always* be made to be deterministic.  That is
  19.    > : one of the major attractions to manual memory management in 
  20.    > : real time systems.  You can use malloc/free (new/delete) pairs which are
  21.    > : 100% predictable.
  22.    > 
  23.  
  24. mbk@caffeine.engr.utk.edu (Matt Kennel) writes:
  25.    > Are they?  Have you gone through the all the possible orderings of
  26.    > previous 'new' and 'malloc' so that you ***KNOW*** exactly
  27.    > what the internal heap structures are so that subsequent calls to 
  28.    > 'malloc' and 'new' and 'free' take a known amount of time?
  29.  
  30. jsa@organon.com (Jon S Anthony) writes:
  31.  
  32.    Actually, it is even worse than you are suggesting as Malloc/new and
  33.    free are not necessarily very predictable and can exhibit "bad" behavior
  34.    depending on their use.
  35.  
  36. You missed my point.  new/delete can *always be made* to be completely
  37. deterministic.  Consider:
  38.  
  39. struct block
  40. {
  41.   block* link;
  42.   char space[100];
  43. };
  44.  
  45. static block  freestore[1000];
  46. static int    allocPoint = 0;
  47. static block* freeList = 0;
  48.  
  49. void* operator new(size_t s)
  50. {
  51.   void* p = 0;
  52.   if (s <= sizeof(block)) // not too big.
  53.   {
  54.     if (freeList)
  55.     {
  56.       p = freeList;
  57.       freeList=freeList->link;
  58.     }
  59.     else if (allocPoint < 1000)
  60.     {
  61.       p = freestore+allocPoint++;
  62.     }
  63.   }
  64.   return p;
  65. };
  66.  
  67. void operator delete(void* p)
  68. {
  69.   block* bp = (block*)p;
  70.   bp->link = freeList;
  71.   freeList = bp;
  72. };
  73.  
  74. Now, this example is very very simplistic, (and I didn't compile it so it
  75. probably has some errors in it) however it provides a version of new
  76. and delete that are almost complete deterministic.  The only ambiguity
  77. occurs when the freeList is empty.  Even this small non-determinism
  78. could be eliminated if the freeList were linked up with all 1000
  79. blocks prior the start of the program.
  80.  
  81. This is a typical strategy in real time systems.  Note that one trades
  82. determinism for memory inefficiency.  In the system above, even when
  83. somebody just wants 5 bytes, they still get all sizeof(block) bytes.
  84. This can be mitigated by creating a tiered structure.  But it can
  85. never by perfectly eliminated.
  86.  
  87. --
  88. Robert Martin       | Design Consulting   | Training courses offered:
  89. Object Mentor Assoc.| rmartin@oma.com     |   OOA/D, C++, Advanced OO
  90. 14619 N. Somerset Cr| Tel: (847) 918-1004 |   Mgt. Overview of OOT
  91. Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
  92.  
  93.